Skip to content

NO TICKET: make pytest and behave interoperable#234

Merged
jirhiker merged 3 commits into
stagingfrom
jab-behave-environment-fix
Nov 6, 2025
Merged

NO TICKET: make pytest and behave interoperable#234
jirhiker merged 3 commits into
stagingfrom
jab-behave-environment-fix

Conversation

@jacob-a-brown

Copy link
Copy Markdown
Contributor

Why

This PR addresses the following problem / context:

I'm running into errors seeding the testing data for behave tests. This occurs after I run pytest (either on its own or for git commit), which erases and repopulates the database for the pytest tests. It does not, however, teardown and build the database back up. Because of this, the ids of all tables get incremented, so when behave testing data are added that depend on a hardcoded id (sensor, deployment) an error occurs because that id is out of date.

How

Implementation summary - the following was changed / added / removed:

  • use objects and their auto-generated IDs to prevent hardcoding values

Notes

Any special considerations, workarounds, or follow-up work to note?

  • Because of this flexible implementation, I can no longer check if an object exists via hardcoded ids. Due to this, unique constraints are broken. To address this, I tear down all of the testing data in after_all. This should be quicker and easier than running erase_and_rebuild_db at the start of every behave testing session

@jacob-a-brown jacob-a-brown changed the title NO TICKET: make pytest and behave interoperable by default NO TICKET: make pytest and behave interoperable Nov 6, 2025
@codecov-commenter

codecov-commenter commented Nov 6, 2025

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.
see 5 files with indirect coverage changes

@jirhiker

jirhiker commented Nov 6, 2025

Copy link
Copy Markdown
Member

I don't understand why this is preferable. What issues were you having seeding the database. The current solution is idempotent

@jacob-a-brown

Copy link
Copy Markdown
Contributor Author

When pytest is run it creates a bunch of data, thereby auto-incrementing the id in each table. Then, when behave is run it adds the different objects. Because of the auto-incrementing from pytest the hardcoded ids are out of date. This causes two issues with the data that is being seeded:

  1. if sh run_bdd.sh is run more than once, it will try to add a second sensor with the same serial_no, which breaks the unique constraint.
  2. the hardcoded thing_id and sensor_id in the deployment are no longer valid.

@jacob-a-brown

Copy link
Copy Markdown
Contributor Author

By keeping it flexible and tearing down the data after each test we won't have to worry about ids and the order in which tests are run (pytest or behave), and during development we can call sh run_bdd.sh any number of times and the unique constraints won't be broken.

@jirhiker

jirhiker commented Nov 6, 2025

Copy link
Copy Markdown
Member

I don't see the point of removing seed data. Removing data added by a test is acceptable, but removing seed data solely to re-add it does not make sense. The seed functions need to be idempotent (and for the most part, they are) without requiring the removal of data add the end of a test suite.

@jirhiker jirhiker left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will approve this to keep this moving forward. I don't see that as a necessary solution now but it seems to address the issues you are having

@jirhiker jirhiker merged commit 7727e6c into staging Nov 6, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants